path: root/73/eb034265ada9b5b2cad07cf10ec3281c2b4935

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dgomez1092@gmail.com>) id 1YruC9-00008S-10
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 20:20:57 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.42 as permitted sender)
	client-ip=74.125.82.42; envelope-from=dgomez1092@gmail.com;
	helo=mail-wg0-f42.google.com; 
Received: from mail-wg0-f42.google.com ([74.125.82.42])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YruC5-0006Sz-0M
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 20:20:57 +0000
Received: by wgbhc8 with SMTP id hc8so40411847wgb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 11 May 2015 13:20:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.160.169 with SMTP id xl9mr23968492wib.42.1431375646926; 
	Mon, 11 May 2015 13:20:46 -0700 (PDT)
Received: by 10.28.144.68 with HTTP; Mon, 11 May 2015 13:20:46 -0700 (PDT)
In-Reply-To: <mailman.239076.1431365350.2287.bitcoin-development@lists.sourceforge.net>
References: <mailman.239076.1431365350.2287.bitcoin-development@lists.sourceforge.net>
Date: Mon, 11 May 2015 13:20:46 -0700
Message-ID: <CAH+jCTzgd+o56SNZ-UGaUhyOxSf+wa=k=T4++vMN_vMJCi4xww@mail.gmail.com>
From: Damian Gomez <dgomez1092@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b624ac2f9b0370515d41cb9
X-Spam-Score: 0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(dgomez1092[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (dgomez1092[at]gmail.com)
	0.6 URIBL_SBL Contains an URL's NS IP listed in the SBL blocklist
	[URIs: dashjr.org]
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YruC5-0006Sz-0M
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
	Issue 62
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 20:20:57 -0000

--047d7b624ac2f9b0370515d41cb9
Content-Type: text/plain; charset=UTF-8

Hllo

I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.

It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every  Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions.  This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the "brainers" of a systems who are then the "signatuers" of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order  to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.

There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.

This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information)> There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)

Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information.  The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.


FYI(thank you to peter whom nudged my thinking and interest (again) in this
area. )

This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it).  I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.



*Also, might someone be able to provide a bit of information on Bitcoin
core project?*

thank you again. Damain.

On Mon, May 11, 2015 at 10:29 AM, <
bitcoin-development-request@lists.sourceforge.net> wrote:

> Send Bitcoin-development mailing list submissions to
>         bitcoin-development@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> or, via email, send a message with subject or body 'help' to
>         bitcoin-development-request@lists.sourceforge.net
>
> You can reach the person managing the list at
>         bitcoin-development-owner@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bitcoin-development digest..."
>
> Today's Topics:
>
>    1. Fwd:  Bitcoin core 0.11 planning (Wladimir)
>    2. Re: Bitcoin core 0.11 planning (Wladimir)
>    3. Long-term mining incentives (Thomas Voegtlin)
>    4. Re: Long-term mining incentives
>       (insecurity@national.shitposting.agency)
>    5. Re: Reducing the block rate instead of    increasing the maximum
>       block size (Luke Dashjr)
>    6. Re: Long-term mining incentives (Gavin Andresen)
>
>
> ---------- Forwarded message ----------
> From: Wladimir <laanwj@gmail.com>
> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Cc:
> Date: Mon, 11 May 2015 14:49:53 +0000
> Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning
> On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
> > As softforks almost certainly require backports to older releases and
> other
> > software anyway, I don't think they should necessarily be bound to
> Bitcoin
> > Core major releases. If they don't require large code changes, we can
> easily
> > do them in minor releases too.
>
> Agree here - there is no need to time consensus changes with a major
> release, as they need to be ported back to older releases anyhow.
> (I don't really classify them as software features, but properties of
> the underlying system that we need to adopt to)
>
> Wladimir
>
>
>
>
> ---------- Forwarded message ----------
> From: Wladimir <laanwj@gmail.com>
> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Cc:
> Date: Mon, 11 May 2015 15:00:03 +0000
> Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
> A reminder - feature freeze and string freeze is coming up this Friday the
> 15th.
>
> Let me know if your pull request is ready to be merged before then,
>
> Wladimir
>
> On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
> <laanwj@gmail.com> wrote:
> > Hello all,
> >
> > The release window for 0.11 is nearing, I'd propose the following
> schedule:
> >
> > 2015-05-01  Soft translation string freeze
> >             Open Transifex translations for 0.11
> >             Finalize and close translation for 0.9
> >
> > 2015-05-15  Feature freeze, string freeze
> >
> > 2015-06-01  Split off 0.11 branch
> >             Tag and release 0.11.0rc1
> >             Start merging for 0.12 on master branch
> >
> > 2015-07-01  Release 0.11.0 final (aim)
> >
> > In contrast to former releases, which were protracted for months, let's
> try to be more strict about the dates. Of course it is always possible for
> last-minute critical issues to interfere with the planning. The release
> will not be held up for features, though, and anything that will not make
> it to 0.11 will be postponed to next release scheduled for end of the year.
> >
> > Wladimir
>
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
> Cc:
> Date: Mon, 11 May 2015 18:28:46 +0200
> Subject: [Bitcoin-development] Long-term mining incentives
> The discussion on block size increase has brought some attention to the
> other elephant in the room: Long-term mining incentives.
>
> Bitcoin derives its current market value from the assumption that a
> stable, steady-state regime will be reached in the future, where miners
> have an incentive to keep mining to protect the network. Such a steady
> state regime does not exist today, because miners get most of their
> reward from the block subsidy, which will progressively be removed.
>
> Thus, today's 3 billion USD question is the following: Will a steady
> state regime be reached in the future? Can such a regime exist? What are
> the necessary conditions for its existence?
>
> Satoshi's paper suggests that this may be achieved through miner fees.
> Quite a few people seem to take this for granted, and are working to
> make it happen (developing cpfp and replace-by-fee). This explains part
> of the opposition to raising the block size limit; some people would
> like to see some fee pressure building up first, in order to get closer
> to a regime where miners are incentivised by transaction fees instead of
> block subsidy. Indeed, the emergence of a working fee market would be
> extremely reassuring for the long-term viability of bitcoin. So, the
> thinking goes, by raising the block size limit, we would be postponing a
> crucial reality check. We would be buying time, at the expenses of
> Bitcoin's decentralization.
>
> OTOH, proponents of a block size increase have a very good point: if the
> block size is not raised soon, Bitcoin is going to enter a new, unknown
> and potentially harmful regime. In the current regime, almost all
> transaction get confirmed quickly, and fee pressure does not exist. Mike
> Hearn suggested that, when blocks reach full capacity and users start to
> experience confirmation delays and confirmation uncertainty, users will
> simply go away and stop using Bitcoin. To me, that outcome sounds very
> plausible indeed. Thus, proponents of the block size increase are
> conservative; they are trying to preserve the current regime, which is
> known to work, instead of letting the network enter uncharted territory.
>
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain infrastructure first, such as the
> Lightning network.
>
> OTOH, I also fail to see evidence that a limited block capacity will
> lead to a functional fee market, able to sustain a steady state. A
> functional market requires well-informed participants who make rational
> choices and accept the outcomes of their choices. That is not the case
> today, and to believe that it will magically happen because blocks start
> to reach full capacity sounds a lot like like wishful thinking.
>
> So here is my question, to both proponents and opponents of a block size
> increase: What steady-state regime do you envision for Bitcoin, and what
> is is your plan to get there? More specifically, how will the
> steady-state regime look like? Will users experience fee pressure and
> delays, or will it look more like a scaled up version of what we enjoy
> today? Should fee pressure be increased jointly with subsidy decrease,
> or as soon as possible, or never? What incentives will exist for miners
> once the subsidy is gone? Will miners have an incentive to permanently
> fork off the last block and capture its fees? Do you expect Bitcoin to
> work because miners are altruistic/selfish/honest/caring?
>
> A clear vision would be welcome.
>
>
>
>
> ---------- Forwarded message ----------
> From: insecurity@national.shitposting.agency
> To: thomasv@electrum.org
> Cc: bitcoin-development@lists.sourceforge.net
> Date: Mon, 11 May 2015 16:52:10 +0000
> Subject: Re: [Bitcoin-development] Long-term mining incentives
> On 2015-05-11 16:28, Thomas Voegtlin wrote:
>
>> My problem is that this seems to lacks a vision. If the maximal block
>> size is increased only to buy time, or because some people think that 7
>> tps is not enough to compete with VISA, then I guess it would be
>> healthier to try and develop off-chain infrastructure first, such as the
>> Lightning network.
>>
>
> If your end goal is "compete with VISA" you might as well just give up
> and go home right now. There's lots of terrible proposals where people
> try to demonstrate that so many hundred thousand transactions a second
> are possible if we just make the block size 500GB. In the real world
> with physical limits, you literally can not verify more than a few
> thousand ECDSA signatures a second on a CPU core. The tradeoff taken
> in Bitcoin is that the signatures are pretty small, but they are also
> slow to verify on any sort of scale. There's no way competing with a
> centralised entity using on-chain transactions is even a sane goal.
>
>
>
>
> ---------- Forwarded message ----------
> From: Luke Dashjr <luke@dashjr.org>
> To: bitcoin-development@lists.sourceforge.net
> Cc:
> Date: Mon, 11 May 2015 16:47:47 +0000
> Subject: Re: [Bitcoin-development] Reducing the block rate instead of
> increasing the maximum block size
> On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
> > 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
> >
> > 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.
>
> 1. Latency is what matters here, not bandwidth so much. And latency
> reduction
> is either expensive or impossible.
> 2. Mining pools are mostly run at a loss (with exception to only the most
> centralised pools), and have nothing to invest in increasing
> infrastructure.
>
> > 3, It will reduce the security of the network
> >
> > 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.
> >
> > 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.
>
> You're overlooking at least:
> 1. The real network has to suffer wasted work as a result of the stale
> blocks,
> while an attacker does not. If 20% of blocks are stale, the attacker only
> needs 40% of the legitimate hashrate to achieve 50%-in-practice.
> 2. Since blocks are individually weaker, it becomes cheaper to DoS nodes
> with
> invalid blocks. (not sure if this is a real concern, but it ought to be
> considered and addressed)
>
> > 4. Reducing the block propagation time on the average case is good, but
> > what happen in the worse case?
> >
> > 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
> > 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.
>
> One can probably overcome changing network conditions merely by trying to
> reach 75% and exclude the slowest 25%. Also, there is no way to identify or
> blacklist miners.
>
> > 5. Thousands of SPV wallets running in mobile devices would need to be
> > upgraded (thanks Mike).
> >
> > 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.
>
> I agree this shouldn't be a real concern. SPV wallets are also more likely
> and
> less risky (globally) to be auto-updated.
>
> > 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
> >
> > 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.
>
> Uh, I think you need to be using at least median speeds. As an example, I
> can
> only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G
> has
> worse range/coverage than 2G. No doubt the *average* is skewed so high
> because
> of densely populated areas like San Francisco having 400+ Mbps cellular
> data.
> It's not reasonable to assume sync only at night: most payments will be
> during
> the day, on battery - so increased power use must also be considered.
>
> > According to CISCO mobile bandwidth connection speed increases 20% every
> > year.
>
> Only in small densely populated areas of first-world countries.
>
> Luke
>
>
>
>
> ---------- Forwarded message ----------
> From: Gavin Andresen <gavinandresen@gmail.com>
> To: insecurity@national.shitposting.agency
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Date: Mon, 11 May 2015 13:29:02 -0400
> Subject: Re: [Bitcoin-development] Long-term mining incentives
> I think long-term the chain will not be secured purely by proof-of-work. I
> think when the Bitcoin network was tiny running solely on people's home
> computers proof-of-work was the right way to secure the chain, and the only
> fair way to both secure the chain and distribute the coins.
>
> See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a  for some
> half-baked thoughts along those lines. I don't think proof-of-work is the
> last word in distributed consensus (I also don't think any alternatives are
> anywhere near ready to deploy, but they might be in ten years).
>
> I also think it is premature to worry about what will happen in twenty or
> thirty years when the block subsidy is insignificant. A lot will happen in
> the next twenty years. I could spin a vision of what will secure the chain
> in twenty years, but I'd put a low probability on that vision actually
> turning out to be correct.
>
> That is why I keep saying Bitcoin is an experiment. But I also believe
> that the incentives are correct, and there are a lot of very motivated,
> smart, hard-working people who will make it work. When you're talking about
> trying to predict what will happen decades from now, I think that is the
> best you can (honestly) do.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> 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
>
>

--047d7b624ac2f9b0370515d41cb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hllo=C2=A0<div><br></div><div>I want to build from a conve=
rsation that I had w/ Peter (T?) regarding the increase in block size in th=
e bitcoin from its&#39;s current structure would be the proposasl of an pre=
pend to the hash chain itself that would be the first DER decoded script in=
 order to verify integrity(trust) within a set of transactions and the orig=
iniator themselves.=C2=A0</div><div><br></div><div>It is my belief that the=
 process to begin a new encryption tool using a variant of the WinterNitz O=
TS for its existential unforgeability to be the added signatures with every=
 =C2=A0Wallet transaction in order to provide a consesnus systemt that take=
s into accont a personal level of intergrity for the intention fo a transac=
tion to occur. This signature would then be hashes for there to be an inter=
mediate proxy state that then verifies and evaluates the trust fucntion for=
 the receiving trnsactions.=C2=A0 This evaluation loop would itself be a st=
ate in which the mining power and the rewards derived from them would be an=
 increased level of integrity as provided for the &quot;brainers&quot; of a=
 systems who are then the &quot;signatuers&quot; of the transaction authent=
icity, and additiaonally program extranonces of x bits {72} in order =C2=A0=
to have a double valid signature that the rest of the nodes would accept in=
 order to have a valid address from which to be able to continuously receiv=
e transactions.=C2=A0</div><div><br></div><div>There is a level of diffcult=
y in obtaining brainers, fees would only apply uin so much as they are able=
 to create authentic transactions based off the voting power of the rest of=
 the received nodes. The greater number of faults within the system from a =
brainer then the more, so would his computational power be restricted in or=
der to provide a reward feedback system. This singularity in a Byzantine co=
nsensus is only achieved if the route of an appropriate transformation occu=
rs, one that is invariant to the participants of the system, thus being abl=
e to provide initial vector transformations from a person&#39;s online iden=
tity is the responsibilty that we have to ensure and calulate a lagrangian =
method that utilisizes a set of convolutional neural network funcitons [bac=
kpropagation, fuzzy logic] and and tranformation function taking the vector=
s of tranformations in a kahunen-loeve algorithm and using the convergence =
of a baryon wave function in order to proceed with a baseline reading of th=
e current level of integrity in the state today that is an instance of acti=
onable acceleration within a system. =C2=A0</div><div><br></div><div>This i=
s something that I am trying to continue to parse out. Therefore there are =
still heavy questions to be answered(the most important being the consent o=
f the people to measure their own levels of integrity through mined informa=
tion)&gt; There must always be the option to disconnect from a transactiona=
l system where payments occur in order to allow a level of solace and peace=
 within individuals -- withour repercussions and a seperate system that sup=
ports the offline realm as well. (THis is a design problem)</div><div><br><=
/div><div>Ultimately, quite literally such a transaction system could exist=
 to provide detailed analysis that promotes integrity being the basis for s=
haring information.=C2=A0 The fee structure would be eliminated, due to the=
 level of integrity and procesing power to have messages and transactions a=
nd reviews of unfiduciary responsible orgnizations be merited as highly tru=
e (.9 in fizzy logic) in order to promote a well-being in the state. That i=
s its own reward, the strenght of having more processing speed.</div><div><=
br></div><div><br></div><div>FYI(thank you to peter whom nudged my thinking=
 and interest (again) in this area. )</div><div><br></div><div>This is some=
thing I am attempting to design in order to program it. Though I am not an =
expert and my technology stack is limited to java and c (and my issues from=
 it).=C2=A0 I provided a class the other day the was pseudo code for the be=
ginning of the consensus. Now I might to now if I am missing any of teh tec=
hnical paradigms that might make this illogical? I now with the advent of 7=
petabyte computers one could easily store 2.5 petabytes of human informatio=
n for just an instance of integrity not to mention otehr emotions.=C2=A0</d=
iv><div><br></div><div><br></div><div><br></div><div><font color=3D"#bf9000=
" size=3D"4"><b>Also, might someone be able to provide a bit of information=
 on Bitcoin core project?</b></font></div><div><br></div><div>thank you aga=
in. Damain. =C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Mon, May 11, 2015 at 10:29 AM,  <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-development-request@lists.sourceforge.net" target=3D"_=
blank">bitcoin-development-request@lists.sourceforge.net</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">Send Bitcoin-development mailing list=
 submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development@lists.sou=
rceforge.net">bitcoin-development@lists.sourceforge.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development" target=3D"_blank">https://lists.sourceforge.n=
et/lists/listinfo/bitcoin-development</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-request@l=
ists.sourceforge.net">bitcoin-development-request@lists.sourceforge.net</a>=
<br>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-owner@lis=
ts.sourceforge.net">bitcoin-development-owner@lists.sourceforge.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Bitcoin-development digest...&quot;<br>
<br>Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. Fwd:=C2=A0 Bitcoin core 0.11 planning (Wladimir)<br>
=C2=A0 =C2=A02. Re: Bitcoin core 0.11 planning (Wladimir)<br>
=C2=A0 =C2=A03. Long-term mining incentives (Thomas Voegtlin)<br>
=C2=A0 =C2=A04. Re: Long-term mining incentives<br>
=C2=A0 =C2=A0 =C2=A0 (insecurity@national.shitposting.agency)<br>
=C2=A0 =C2=A05. Re: Reducing the block rate instead of=C2=A0 =C2=A0 increas=
ing the maximum<br>
=C2=A0 =C2=A0 =C2=A0 block size (Luke Dashjr)<br>
=C2=A0 =C2=A06. Re: Long-term mining incentives (Gavin Andresen)<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Wladimir &lt;=
<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>&gt;<br>To:=C2=A0Bi=
tcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge.net">=
bitcoin-development@lists.sourceforge.net</a>&gt;<br>Cc:=C2=A0<br>Date:=C2=
=A0Mon, 11 May 2015 14:49:53 +0000<br>Subject:=C2=A0[Bitcoin-development] F=
wd:  Bitcoin core 0.11 planning<br>On Tue, Apr 28, 2015 at 11:01 AM, Pieter=
 Wuille &lt;<a href=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.=
com</a>&gt; wrote:<br>
&gt; As softforks almost certainly require backports to older releases and =
other<br>
&gt; software anyway, I don&#39;t think they should necessarily be bound to=
 Bitcoin<br>
&gt; Core major releases. If they don&#39;t require large code changes, we =
can easily<br>
&gt; do them in minor releases too.<br>
<br>
Agree here - there is no need to time consensus changes with a major<br>
release, as they need to be ported back to older releases anyhow.<br>
(I don&#39;t really classify them as software features, but properties of<b=
r>
the underlying system that we need to adopt to)<br>
<br>
Wladimir<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Wladimir &lt;=
<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>&gt;<br>To:=C2=A0Bi=
tcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge.net">=
bitcoin-development@lists.sourceforge.net</a>&gt;<br>Cc:=C2=A0<br>Date:=C2=
=A0Mon, 11 May 2015 15:00:03 +0000<br>Subject:=C2=A0Re: [Bitcoin-developmen=
t] Bitcoin core 0.11 planning<br>A reminder - feature freeze and string fre=
eze is coming up this Friday the 15th.<br>
<br>
Let me know if your pull request is ready to be merged before then,<br>
<br>
Wladimir<br>
<br>
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan<br>
&lt;<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>&gt; wrote:<br>
&gt; Hello all,<br>
&gt;<br>
&gt; The release window for 0.11 is nearing, I&#39;d propose the following =
schedule:<br>
&gt;<br>
&gt; 2015-05-01=C2=A0 Soft translation string freeze<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Open Transifex translat=
ions for 0.11<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finalize and close tran=
slation for 0.9<br>
&gt;<br>
&gt; 2015-05-15=C2=A0 Feature freeze, string freeze<br>
&gt;<br>
&gt; 2015-06-01=C2=A0 Split off 0.11 branch<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tag and release 0.11.0r=
c1<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Start merging for 0.12 =
on master branch<br>
&gt;<br>
&gt; 2015-07-01=C2=A0 Release 0.11.0 final (aim)<br>
&gt;<br>
&gt; In contrast to former releases, which were protracted for months, let&=
#39;s try to be more strict about the dates. Of course it is always possibl=
e for last-minute critical issues to interfere with the planning. The relea=
se will not be held up for features, though, and anything that will not mak=
e it to 0.11 will be postponed to next release scheduled for end of the yea=
r.<br>
&gt;<br>
&gt; Wladimir<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Thomas Voegtl=
in &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@electrum.org</a>&gt;=
<br>To:=C2=A0Bitcoin Development &lt;<a href=3D"mailto:bitcoin-development@=
lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>&gt;<br=
>Cc:=C2=A0<br>Date:=C2=A0Mon, 11 May 2015 18:28:46 +0200<br>Subject:=C2=A0[=
Bitcoin-development] Long-term mining incentives<br>The discussion on block=
 size increase has brought some attention to the<br>
other elephant in the room: Long-term mining incentives.<br>
<br>
Bitcoin derives its current market value from the assumption that a<br>
stable, steady-state regime will be reached in the future, where miners<br>
have an incentive to keep mining to protect the network. Such a steady<br>
state regime does not exist today, because miners get most of their<br>
reward from the block subsidy, which will progressively be removed.<br>
<br>
Thus, today&#39;s 3 billion USD question is the following: Will a steady<br=
>
state regime be reached in the future? Can such a regime exist? What are<br=
>
the necessary conditions for its existence?<br>
<br>
Satoshi&#39;s paper suggests that this may be achieved through miner fees.<=
br>
Quite a few people seem to take this for granted, and are working to<br>
make it happen (developing cpfp and replace-by-fee). This explains part<br>
of the opposition to raising the block size limit; some people would<br>
like to see some fee pressure building up first, in order to get closer<br>
to a regime where miners are incentivised by transaction fees instead of<br=
>
block subsidy. Indeed, the emergence of a working fee market would be<br>
extremely reassuring for the long-term viability of bitcoin. So, the<br>
thinking goes, by raising the block size limit, we would be postponing a<br=
>
crucial reality check. We would be buying time, at the expenses of<br>
Bitcoin&#39;s decentralization.<br>
<br>
OTOH, proponents of a block size increase have a very good point: if the<br=
>
block size is not raised soon, Bitcoin is going to enter a new, unknown<br>
and potentially harmful regime. In the current regime, almost all<br>
transaction get confirmed quickly, and fee pressure does not exist. Mike<br=
>
Hearn suggested that, when blocks reach full capacity and users start to<br=
>
experience confirmation delays and confirmation uncertainty, users will<br>
simply go away and stop using Bitcoin. To me, that outcome sounds very<br>
plausible indeed. Thus, proponents of the block size increase are<br>
conservative; they are trying to preserve the current regime, which is<br>
known to work, instead of letting the network enter uncharted territory.<br=
>
<br>
My problem is that this seems to lacks a vision. If the maximal block<br>
size is increased only to buy time, or because some people think that 7<br>
tps is not enough to compete with VISA, then I guess it would be<br>
healthier to try and develop off-chain infrastructure first, such as the<br=
>
Lightning network.<br>
<br>
OTOH, I also fail to see evidence that a limited block capacity will<br>
lead to a functional fee market, able to sustain a steady state. A<br>
functional market requires well-informed participants who make rational<br>
choices and accept the outcomes of their choices. That is not the case<br>
today, and to believe that it will magically happen because blocks start<br=
>
to reach full capacity sounds a lot like like wishful thinking.<br>
<br>
So here is my question, to both proponents and opponents of a block size<br=
>
increase: What steady-state regime do you envision for Bitcoin, and what<br=
>
is is your plan to get there? More specifically, how will the<br>
steady-state regime look like? Will users experience fee pressure and<br>
delays, or will it look more like a scaled up version of what we enjoy<br>
today? Should fee pressure be increased jointly with subsidy decrease,<br>
or as soon as possible, or never? What incentives will exist for miners<br>
once the subsidy is gone? Will miners have an incentive to permanently<br>
fork off the last block and capture its fees? Do you expect Bitcoin to<br>
work because miners are altruistic/selfish/honest/caring?<br>
<br>
A clear vision would be welcome.<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0insecurity@na=
tional.shitposting.agency<br>To:=C2=A0<a href=3D"mailto:thomasv@electrum.or=
g">thomasv@electrum.org</a><br>Cc:=C2=A0<a href=3D"mailto:bitcoin-developme=
nt@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><br>=
Date:=C2=A0Mon, 11 May 2015 16:52:10 +0000<br>Subject:=C2=A0Re: [Bitcoin-de=
velopment] Long-term mining incentives<br>On 2015-05-11 16:28, Thomas Voegt=
lin wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My problem is that this seems to lacks a vision. If the maximal block<br>
size is increased only to buy time, or because some people think that 7<br>
tps is not enough to compete with VISA, then I guess it would be<br>
healthier to try and develop off-chain infrastructure first, such as the<br=
>
Lightning network.<br>
</blockquote>
<br>
If your end goal is &quot;compete with VISA&quot; you might as well just gi=
ve up<br>
and go home right now. There&#39;s lots of terrible proposals where people<=
br>
try to demonstrate that so many hundred thousand transactions a second<br>
are possible if we just make the block size 500GB. In the real world<br>
with physical limits, you literally can not verify more than a few<br>
thousand ECDSA signatures a second on a CPU core. The tradeoff taken<br>
in Bitcoin is that the signatures are pretty small, but they are also<br>
slow to verify on any sort of scale. There&#39;s no way competing with a<br=
>
centralised entity using on-chain transactions is even a sane goal.<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Luke Dashjr &=
lt;<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>&gt;<br>To:=C2=A0<=
a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-develop=
ment@lists.sourceforge.net</a><br>Cc:=C2=A0<br>Date:=C2=A0Mon, 11 May 2015 =
16:47:47 +0000<br>Subject:=C2=A0Re: [Bitcoin-development] Reducing the bloc=
k rate instead of increasing the maximum block size<br>On Monday, May 11, 2=
015 7:03:29 AM Sergio Lerner wrote:<br>
&gt; 1. It will encourage centralization, because participants of mining<br=
>
&gt; pools will loose more money because of excessive initial block templat=
e<br>
&gt; latency, which leads to higher stale shares<br>
&gt;<br>
&gt; When a new block is solved, that information needs to propagate<br>
&gt; throughout the Bitcoin network up to the mining pool operator nodes,<b=
r>
&gt; then a new block header candidate is created, and this header must be<=
br>
&gt; propagated to all the mining pool users, ether by a push or a pull<br>
&gt; model. Generally the mining server pushes new work units to the<br>
&gt; individual miners. If done other way around, the server would need to<=
br>
&gt; handle a high load of continuous work requests that would be difficult=
<br>
&gt; to distinguish from a DDoS attack. So if the server pushes new block<b=
r>
&gt; header candidates to clients, then the problem boils down to increasin=
g<br>
&gt; bandwidth of the servers to achieve a tenfold increase in work<br>
&gt; distribution. Or distributing the servers geographically to achieve a<=
br>
&gt; lower latency. Propagating blocks does not require additional CPU<br>
&gt; resources, so mining pools administrators would need to increase<br>
&gt; moderately their investment in the server infrastructure to achieve<br=
>
&gt; lower latency and higher bandwidth, but I guess the investment would b=
e<br>
&gt; low.<br>
<br>
1. Latency is what matters here, not bandwidth so much. And latency reducti=
on<br>
is either expensive or impossible.<br>
2. Mining pools are mostly run at a loss (with exception to only the most<b=
r>
centralised pools), and have nothing to invest in increasing infrastructure=
.<br>
<br>
&gt; 3, It will reduce the security of the network<br>
&gt;<br>
&gt; The security of the network is based on two facts:<br>
&gt; A- The miners are incentivized to extend the best chain<br>
&gt; B- The probability of a reversal based on a long block competition<br>
&gt; decreases as more confirmation blocks are appended.<br>
&gt; C- Renting or buying hardware to perform a 51% attack is costly.<br>
&gt;<br>
&gt; A still holds. B holds for the same amount of confirmation blocks, so =
6<br>
&gt; confirmation blocks in a 10-minute block-chain is approximately<br>
&gt; equivalent to 6 confirmation blocks in a 1-minute block-chain.<br>
&gt; Only C changes, as renting the hashing power for 6 minutes is ten time=
s<br>
&gt; less expensive as renting it for 1 hour. However, there is no shop whe=
re<br>
&gt; one can find 51% of the hashing power to rent right now, nor probably<=
br>
&gt; will ever be if Bitcoin succeeds. Last, you can still have a 1 hour<br=
>
&gt; confirmation (60 1-minute blocks) if you wish for high-valued payments=
,<br>
&gt; so the security decreases only if participant wish to decrease it.<br>
<br>
You&#39;re overlooking at least:<br>
1. The real network has to suffer wasted work as a result of the stale bloc=
ks,<br>
while an attacker does not. If 20% of blocks are stale, the attacker only<b=
r>
needs 40% of the legitimate hashrate to achieve 50%-in-practice.<br>
2. Since blocks are individually weaker, it becomes cheaper to DoS nodes wi=
th<br>
invalid blocks. (not sure if this is a real concern, but it ought to be<br>
considered and addressed)<br>
<br>
&gt; 4. Reducing the block propagation time on the average case is good, bu=
t<br>
&gt; what happen in the worse case?<br>
&gt;<br>
&gt; Most methods proposed to reduce the block propagation delay do it only=
<br>
&gt; on the average case. Any kind of block compression relies on both<br>
&gt; parties sharing some previous information. In the worse case it&#39;s =
true<br>
&gt; that a miner can create and try to broadcast a block that takes too mu=
ch<br>
&gt; time to verify or bandwidth to transmit. This is currently true on the=
<br>
&gt; Bitcoin network. Nevertheless there is no such incentive for miners,<b=
r>
&gt; since they will be shooting on their own foots. Peter Todd has argued<=
br>
&gt; that the best strategy for miners is actually to reach 51% of the<br>
&gt; network, but not more. In other words, to exclude the slowest 49%<br>
&gt; percent. But this strategy of creating bloated blocks is too risky in<=
br>
&gt; practice, and surely doomed to fail, as network conditions dynamically=
<br>
&gt; change. Also it would be perceived as an attack to the network, and th=
e<br>
&gt; miner (if it is a public mining pool) would be probably blacklisted.<b=
r>
<br>
One can probably overcome changing network conditions merely by trying to<b=
r>
reach 75% and exclude the slowest 25%. Also, there is no way to identify or=
<br>
blacklist miners.<br>
<br>
&gt; 5. Thousands of SPV wallets running in mobile devices would need to be=
<br>
&gt; upgraded (thanks Mike).<br>
&gt;<br>
&gt; That depends on the current upgrade rate for SPV wallets like Bitcoin<=
br>
&gt; Wallet=C2=A0 and BreadWallet. Suppose that the upgrade rate is 80%/yea=
r: we<br>
&gt; develop the source code for the change now and apply the change in Q2<=
br>
&gt; 2016, then=C2=A0 most of the nodes will already be upgraded by when th=
e<br>
&gt; hardfork takes place. Also a public notice telling people to upgrade i=
n<br>
&gt; web pages, bitcointalk, SPV wallets warnings, coindesk, one year in<br=
>
&gt; advance will give plenty of time to SPV wallet users to upgrade.<br>
<br>
I agree this shouldn&#39;t be a real concern. SPV wallets are also more lik=
ely and<br>
less risky (globally) to be auto-updated.<br>
<br>
&gt; 6. If there are 10x more blocks, then there are 10x more block headers=
,<br>
&gt; and that increases the amount of bandwidth SPV wallets need to catch u=
p<br>
&gt; with the chain<br>
&gt;<br>
&gt; A standard smartphone with average cellular downstream speed downloads=
<br>
&gt; 2.6 headers per second (1600 kbits/sec) [3], so if synchronization wer=
e<br>
&gt; to be done only at night when the phone is connected to the power line=
,<br>
&gt; then it would take 9 minutes to synchronize with 1440 headers/day. If =
a<br>
&gt; person should accept a payment, and the smart-phone is 1 day<br>
&gt; out-of-synch, then it takes less time to download all the missing<br>
&gt; headers than to wait for a 10-minute one block confirmation. Obviously=
<br>
&gt; all smartphones with 3G have a downstream bandwidth much higher,<br>
&gt; averaging 1 Mbps. So the whole synchronization will be done less than =
a<br>
&gt; 1-minute block confirmation.<br>
<br>
Uh, I think you need to be using at least median speeds. As an example, I c=
an<br>
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G ha=
s<br>
worse range/coverage than 2G. No doubt the *average* is skewed so high beca=
use<br>
of densely populated areas like San Francisco having 400+ Mbps cellular dat=
a.<br>
It&#39;s not reasonable to assume sync only at night: most payments will be=
 during<br>
the day, on battery - so increased power use must also be considered.<br>
<br>
&gt; According to CISCO mobile bandwidth connection speed increases 20% eve=
ry<br>
&gt; year.<br>
<br>
Only in small densely populated areas of first-world countries.<br>
<br>
Luke<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Gavin Andrese=
n &lt;<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a=
>&gt;<br>To:=C2=A0insecurity@national.shitposting.agency<br>Cc:=C2=A0Bitcoi=
n Dev &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitc=
oin-development@lists.sourceforge.net</a>&gt;<br>Date:=C2=A0Mon, 11 May 201=
5 13:29:02 -0400<br>Subject:=C2=A0Re: [Bitcoin-development] Long-term minin=
g incentives<br><div dir=3D"ltr"><div class=3D"gmail_extra">I think long-te=
rm the chain will not be secured purely by proof-of-work. I think when the =
Bitcoin network was tiny running solely on people&#39;s home computers proo=
f-of-work was the right way to secure the chain, and the only fair way to b=
oth secure the chain and distribute the coins.</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">See=C2=A0<a href=3D"https://gist.g=
ithub.com/gavinandresen/630d4a6c24ac6144482a" target=3D"_blank">https://gis=
t.github.com/gavinandresen/630d4a6c24ac6144482a</a> =C2=A0for some half-bak=
ed thoughts along those lines. I don&#39;t think proof-of-work is the last =
word in distributed consensus (I also don&#39;t think any alternatives are =
anywhere near ready to deploy, but they might be in ten years).</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I also think it i=
s premature to worry about what will happen in twenty or thirty years when =
the block subsidy is insignificant. A lot will happen in the next twenty ye=
ars. I could spin a vision of what will secure the chain in twenty years, b=
ut I&#39;d put a low probability on that vision actually turning out to be =
correct.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">That is why I keep saying Bitcoin is an experiment. But I also belie=
ve that the incentives are correct, and there are a lot of very motivated, =
smart, hard-working people who will make it work. When you&#39;re talking a=
bout trying to predict what will happen decades from now, I think that is t=
he best you can (honestly) do.<br clear=3D"all"><div><br></div>-- <br><div>=
--<br>Gavin Andresen<br></div>
</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--047d7b624ac2f9b0370515d41cb9--