path: root/47/6d2de8622b136efe9e211a0a98a2c27c08c2eb

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dgomez1092@gmail.com>) id 1YruJl-0000aF-MF
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 20:28:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.182 as permitted sender)
	client-ip=209.85.212.182; envelope-from=dgomez1092@gmail.com;
	helo=mail-wi0-f182.google.com; 
Received: from mail-wi0-f182.google.com ([209.85.212.182])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YruJh-0001uF-Mf
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 20:28:49 +0000
Received: by widdi4 with SMTP id di4so121624099wid.0
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 11 May 2015 13:28:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.99.39 with SMTP id en7mr23748511wib.31.1431376119583;
	Mon, 11 May 2015 13:28:39 -0700 (PDT)
Received: by 10.28.144.68 with HTTP; Mon, 11 May 2015 13:28:39 -0700 (PDT)
In-Reply-To: <mailman.66482.1431375657.18600.bitcoin-development@lists.sourceforge.net>
References: <mailman.66482.1431375657.18600.bitcoin-development@lists.sourceforge.net>
Date: Mon, 11 May 2015 13:28:39 -0700
Message-ID: <CAH+jCTxqAAohw_upeTxhT1z1CWhsgwD0P4ofqZ8C=0CCjYZ9sg@mail.gmail.com>
From: Damian Gomez <dgomez1092@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d0418280825da600515d4398a
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: 1YruJh-0001uF-Mf
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
	Issue 63
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:28:49 -0000

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

Btw How awful that I didn't cite my sources, please exucse me, this is
definitely not my intention sometimes I get too caught up in my own
excitemtnt

1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on
Dependable and Secure Computing. 2006. *3(3) doi: <?>  Please see
John-Phillipe Martin and Lorenzo ALvisi

2) https://eprint.iacr.org/2011/191.pdf  One_Time Winternitz Signatures.


On Mon, May 11, 2015 at 1:20 PM, <
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. Re: Bitcoin-development Digest, Vol 48,   Issue 62 (Damian Gomez)
>
>
> ---------- Forwarded message ----------
> From: Damian Gomez <dgomez1092@gmail.com>
> To: bitcoin-development@lists.sourceforge.net
> Cc:
> Date: Mon, 11 May 2015 13:20:46 -0700
> Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
> Issue 62
> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

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

<div dir=3D"ltr">Btw How awful that I didn&#39;t cite my sources, please ex=
ucse me, this is definitely not my intention sometimes I get too caught up =
in my own excitemtnt<div><br></div><div>1) Martin, J., Alvisi, L., Fast Byz=
antine Consensus. <i>IEEE Transactions on Dependable and Secure Computing. =
2006.=C2=A0</i>3(3) doi: &lt;?&gt; =C2=A0Please see John-Phillipe Martin an=
d Lorenzo ALvisi</div><div><br></div><div>2) <a href=3D"https://eprint.iacr=
.org/2011/191.pdf">https://eprint.iacr.org/2011/191.pdf</a> =C2=A0One_Time =
Winternitz Signatures.</div><div>=C2=A0</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Mon, May 11, 2015 at 1:20 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-development-request@lists.sourcefo=
rge.net" target=3D"_blank">bitcoin-development-request@lists.sourceforge.ne=
t</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bitcoin-deve=
lopment 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. Re: Bitcoin-development Digest, Vol 48,=C2=A0 =C2=A0Issue 6=
2 (Damian Gomez)<br>
<br><br>---------- Forwarded message ----------<br>From:=C2=A0Damian Gomez =
&lt;<a href=3D"mailto:dgomez1092@gmail.com">dgomez1092@gmail.com</a>&gt;<br=
>To:=C2=A0<a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitc=
oin-development@lists.sourceforge.net</a><br>Cc:=C2=A0<br>Date:=C2=A0Mon, 1=
1 May 2015 13:20:46 -0700<br>Subject:=C2=A0Re: [Bitcoin-development] Bitcoi=
n-development Digest, Vol 48, Issue 62<br><div dir=3D"ltr">Hllo=C2=A0<div><=
br></div><div>I want to build from a conversation that I had w/ Peter (T?) =
regarding the increase in block size in the bitcoin from its&#39;s current =
structure would be the proposasl of an prepend to the hash chain itself tha=
t would be the first DER decoded script in order to verify integrity(trust)=
 within a set of transactions and the originiator themselves.=C2=A0</div><d=
iv><br></div><div>It is my belief that the process to begin a new encryptio=
n tool using a variant of the WinterNitz OTS for its existential unforgeabi=
lity to be the added signatures with every =C2=A0Wallet transaction in orde=
r to provide a consesnus systemt that takes into accont a personal level of=
 intergrity for the intention fo a transaction to occur. This signature wou=
ld then be hashes for there to be an intermediate proxy state that then ver=
ifies and evaluates the trust fucntion for the receiving trnsactions.=C2=A0=
 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 &quot;brainers&quot; of a systems who are then the &quot;s=
ignatuers&quot; of the transaction authenticity, and additiaonally program =
extranonces of x bits {72} in order =C2=A0to have a double valid signature =
that the rest of the nodes would accept in order to have a valid address fr=
om which to be able to continuously receive transactions.=C2=A0</div><div><=
br></div><div>There is a level of diffculty in obtaining brainers, fees wou=
ld 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 h=
is computational power be restricted in order to provide a reward feedback =
system. This singularity in a Byzantine consensus is only achieved if the r=
oute of an appropriate transformation occurs, one that is invariant to the =
participants of the system, thus being able to provide initial vector trans=
formations from a person&#39;s online identity is the responsibilty that we=
 have to ensure and calulate a lagrangian method that utilisizes a set of c=
onvolutional neural network funcitons [backpropagation, fuzzy logic] and an=
d tranformation function taking the vectors of tranformations in a kahunen-=
loeve algorithm and using the convergence of a baryon wave function in orde=
r to proceed with a baseline reading of the current level of integrity in t=
he state today that is an instance of actionable acceleration within a syst=
em. =C2=A0</div><div><br></div><div>This is something that I am trying to c=
ontinue to parse out. Therefore there are still heavy questions to be answe=
red(the most important being the consent of the people to measure their own=
 levels of integrity through mined information)&gt; There must always be th=
e option to disconnect from a transactional system where payments occur in =
order to allow a level of solace and peace within individuals -- withour re=
percussions and a seperate system that supports the offline realm as well. =
(THis is a design problem)</div><div><br></div><div>Ultimately, quite liter=
ally such a transaction system could exist to provide detailed analysis tha=
t promotes integrity being the basis for sharing information.=C2=A0 The fee=
 structure would be eliminated, due to the level of integrity and procesing=
 power to have messages and transactions and reviews of unfiduciary respons=
ible 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.</div><div><br></div><div><br></div><div>FYI(=
thank you to peter whom nudged my thinking and interest (again) in this are=
a. )</div><div><br></div><div>This is something I am attempting to design i=
n 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 th=
e other day the was pseudo code for the beginning of the consensus. Now I m=
ight 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 easi=
ly store 2.5 petabytes of human information for just an instance of integri=
ty not to mention otehr emotions.=C2=A0</div><div><br></div><div><br></div>=
<div><br></div><div><font color=3D"#bf9000" size=3D"4"><b>Also, might someo=
ne be able to provide a bit of information on Bitcoin core project?</b></fo=
nt></div><div><br></div><div>thank you again. Damain. =C2=A0</div></div><di=
v 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 href=3D"mailto:bitcoin-development-=
request@lists.sourceforge.net" target=3D"_blank">bitcoin-development-reques=
t@lists.sourceforge.net</a>&gt;</span> wrote:<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" target=3D"_blank">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" target=3D"_blank">bitcoin-development-request@lists.s=
ourceforge.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" target=3D"_blank">bitcoin-development-owner@lists.sourc=
eforge.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" target=3D"_blank">laanwj@gmail.com</a>&=
gt;<br>To:=C2=A0Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists=
.sourceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.n=
et</a>&gt;<br>Cc:=C2=A0<br>Date:=C2=A0Mon, 11 May 2015 14:49:53 +0000<br>Su=
bject:=C2=A0[Bitcoin-development] Fwd:  Bitcoin core 0.11 planning<br>On Tu=
e, Apr 28, 2015 at 11:01 AM, Pieter Wuille &lt;<a href=3D"mailto:pieter.wui=
lle@gmail.com" target=3D"_blank">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" target=3D"_blank">laanwj@gmail.com</a>&=
gt;<br>To:=C2=A0Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists=
.sourceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.n=
et</a>&gt;<br>Cc:=C2=A0<br>Date:=C2=A0Mon, 11 May 2015 15:00:03 +0000<br>Su=
bject:=C2=A0Re: [Bitcoin-development] Bitcoin core 0.11 planning<br>A remin=
der - feature freeze and string freeze is coming up this Friday the 15th.<b=
r>
<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" target=3D"_blank">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" target=3D"_blank">thomasv@el=
ectrum.org</a>&gt;<br>To:=C2=A0Bitcoin Development &lt;<a href=3D"mailto:bi=
tcoin-development@lists.sourceforge.net" target=3D"_blank">bitcoin-developm=
ent@lists.sourceforge.net</a>&gt;<br>Cc:=C2=A0<br>Date:=C2=A0Mon, 11 May 20=
15 18:28:46 +0200<br>Subject:=C2=A0[Bitcoin-development] Long-term mining i=
ncentives<br>The discussion on block size increase has brought some attenti=
on 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" target=3D"_blank">thomasv@electrum.org</a><br>Cc:=C2=A0<a href=3D"mailto=
:bitcoin-development@lists.sourceforge.net" target=3D"_blank">bitcoin-devel=
opment@lists.sourceforge.net</a><br>Date:=C2=A0Mon, 11 May 2015 16:52:10 +0=
000<br>Subject:=C2=A0Re: [Bitcoin-development] Long-term mining incentives<=
br>On 2015-05-11 16:28, Thomas Voegtlin 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" target=3D"_blank">luke@dashjr.org</a>=
&gt;<br>To:=C2=A0<a href=3D"mailto:bitcoin-development@lists.sourceforge.ne=
t" target=3D"_blank">bitcoin-development@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 block rate instead of increasing the maxi=
mum block size<br>On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:<b=
r>
&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" target=3D"_blank">gavinand=
resen@gmail.com</a>&gt;<br>To:=C2=A0insecurity@national.shitposting.agency<=
br>Cc:=C2=A0Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists.sou=
rceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.net</=
a>&gt;<br>Date:=C2=A0Mon, 11 May 2015 13:29:02 -0400<br>Subject:=C2=A0Re: [=
Bitcoin-development] Long-term mining incentives<br><div dir=3D"ltr"><div c=
lass=3D"gmail_extra">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&#39;s home computers proof-of-work was the right way to secure t=
he chain, and the only fair way to both secure the chain and distribute the=
 coins.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">See=C2=A0<a href=3D"https://gist.github.com/gavinandresen/630d4a6c24ac614=
4482a" target=3D"_blank">https://gist.github.com/gavinandresen/630d4a6c24ac=
6144482a</a> =C2=A0for some half-baked thoughts along those lines. I don&#3=
9;t think proof-of-work is the last word in distributed consensus (I also d=
on&#39;t think any alternatives are anywhere near ready to deploy, but they=
 might be in ten years).</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">I also think it is premature to worry about what will ha=
ppen in twenty or thirty years when the block subsidy is insignificant. A l=
ot will happen in the next twenty years. I could spin a vision of what will=
 secure the chain in twenty years, but I&#39;d put a low probability on tha=
t vision actually turning out to be correct.<br></div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">That is why I keep saying Bitcoi=
n 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 mak=
e it work. When you&#39;re talking about trying to predict what will happen=
 decades from now, I think that is the 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" target=3D"_bla=
nk">Bitcoin-development@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>
<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>

--f46d0418280825da600515d4398a--