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 ) 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 ; 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: References: Date: Mon, 11 May 2015 13:28:39 -0700 Message-ID: From: Damian Gomez 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 >> To: Bitcoin Dev >> 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 >> 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 >> To: Bitcoin Dev >> 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 >> 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 >> To: Bitcoin Development >> 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 >> 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 >> To: insecurity@national.shitposting.agency >> Cc: Bitcoin Dev >> 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
Btw How awful that I didn't cite my sources, please ex= ucse me, this is definitely not my intention sometimes I get too caught up = in my own excitemtnt

1) Martin, J., Alvisi, L., Fast Byz= antine Consensus. IEEE Transactions on Dependable and Secure Computing. = 2006.=C2=A03(3) doi: <?> =C2=A0Please see John-Phillipe Martin an= d Lorenzo ALvisi

2) https://eprint.iacr.org/2011/191.pdf =C2=A0One_Time = Winternitz Signatures.
=C2=A0

On Mon, May 11, 2015 at 1:20 PM, <bitcoin-development-request@lists.sourceforge.ne= t> wrote:
Send Bitcoin-deve= lopment mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-request@lists.sourceforge.net=

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A01. Re: Bitcoin-development Digest, Vol 48,=C2=A0 =C2=A0Issue 6= 2 (Damian Gomez)


---------- Forwarded message ----------
From:=C2=A0Damian Gomez = <dgomez1092@gmail.com>To:=C2=A0bitc= oin-development@lists.sourceforge.net
Cc:=C2=A0
Date:=C2=A0Mon, 1= 1 May 2015 13:20:46 -0700
Subject:=C2=A0Re: [Bitcoin-development] Bitcoi= n-development Digest, Vol 48, Issue 62
Hllo=C2=A0
<= br>
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 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

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 "brainers" of a systems who are then the "s= ignatuers" 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
<= br>
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'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

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)> 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)

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.


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

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


=

Also, might someo= ne be able to provide a bit of information on Bitcoin core project?

thank you again. Damain. =C2=A0

On Mon, May 11, 2015= at 10:29 AM, <bitcoin-development-reques= t@lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-request@lists.s= ourceforge.net

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-owner@lists.sourc= eforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."

Today's Topics:

=C2=A0 =C2=A01. Fwd:=C2=A0 Bitcoin core 0.11 planning (Wladimir)
=C2=A0 =C2=A02. Re: Bitcoin core 0.11 planning (Wladimir)
=C2=A0 =C2=A03. Long-term mining incentives (Thomas Voegtlin)
=C2=A0 =C2=A04. Re: Long-term mining incentives
=C2=A0 =C2=A0 =C2=A0 (insecurity@national.shitposting.agency)
=C2=A0 =C2=A05. Re: Reducing the block rate instead of=C2=A0 =C2=A0 increas= ing the maximum
=C2=A0 =C2=A0 =C2=A0 block size (Luke Dashjr)
=C2=A0 =C2=A06. Re: Long-term mining incentives (Gavin Andresen)


---------- Forwarded message ----------
From:=C2=A0Wladimir <= laanwj@gmail.com&= gt;
To:=C2=A0Bitcoin Dev <bitcoin-development@lists.sourceforge.n= et>
Cc:=C2=A0
Date:=C2=A0Mon, 11 May 2015 14:49:53 +0000
Su= bject:=C2=A0[Bitcoin-development] Fwd: Bitcoin core 0.11 planning
On Tu= e, 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:=C2=A0Wladimir <= laanwj@gmail.com&= gt;
To:=C2=A0Bitcoin Dev <bitcoin-development@lists.sourceforge.n= et>
Cc:=C2=A0
Date:=C2=A0Mon, 11 May 2015 15:00:03 +0000
Su= bject:=C2=A0Re: [Bitcoin-development] Bitcoin core 0.11 planning
A remin= der - 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<= /a>> wrote:
> Hello all,
>
> The release window for 0.11 is nearing, I'd propose the following = schedule:
>
> 2015-05-01=C2=A0 Soft translation string freeze
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Open Transifex translat= ions for 0.11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finalize and close tran= slation for 0.9
>
> 2015-05-15=C2=A0 Feature freeze, string freeze
>
> 2015-06-01=C2=A0 Split off 0.11 branch
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tag and release 0.11.0r= c1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Start merging for 0.12 = on master branch
>
> 2015-07-01=C2=A0 Release 0.11.0 final (aim)
>
> 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.
>
> Wladimir




---------- Forwarded message ----------
From:=C2=A0Thomas Voegtl= in <thomasv@el= ectrum.org>
To:=C2=A0Bitcoin Development <bitcoin-developm= ent@lists.sourceforge.net>
Cc:=C2=A0
Date:=C2=A0Mon, 11 May 20= 15 18:28:46 +0200
Subject:=C2=A0[Bitcoin-development] Long-term mining i= ncentives
The discussion on block size increase has brought some attenti= on 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.<= br> 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:=C2=A0insecurity@na= tional.shitposting.agency
To:=C2=A0thomasv@electrum.org
Cc:=C2=A0bitcoin-devel= opment@lists.sourceforge.net
Date:=C2=A0Mon, 11 May 2015 16:52:10 +0= 000
Subject:=C2=A0Re: [Bitcoin-development] Long-term mining incentives<= br>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 gi= ve up
and go home right now. There's lots of terrible proposals where people<= br> 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:=C2=A0Luke Dashjr &= lt;luke@dashjr.org= >
To:=C2=A0bitcoin-development@lists.sourceforge.net
Cc:= =C2=A0
Date:=C2=A0Mon, 11 May 2015 16:47:47 +0000
Subject:=C2=A0Re: [= Bitcoin-development] Reducing the block rate instead of increasing the maxi= mum 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 templat= e
> 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<= br> > 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<= br> > 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 increasin= g
> bandwidth of the servers to achieve a tenfold increase in work
> distribution. Or distributing the servers geographically to achieve a<= br> > 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 b= e
> low.

1. Latency is what matters here, not bandwidth so much. And latency reducti= on
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 time= s
> less expensive as renting it for 1 hour. However, there is no shop whe= re
> one can find 51% of the hashing power to rent right now, nor probably<= br> > 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 bloc= ks,
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 wi= th
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, bu= t
> 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 mu= ch
> 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<= br> > 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<= br> > practice, and surely doomed to fail, as network conditions dynamically=
> change. Also it would be perceived as an attack to the network, and th= e
> 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<= br> > Wallet=C2=A0 and BreadWallet. Suppose that the upgrade rate is 80%/yea= r: we
> develop the source code for the change now and apply the change in Q2<= br> > 2016, then=C2=A0 most of the nodes will already be upgraded by when th= e
> hardfork takes place. Also a public notice telling people to upgrade i= n
> 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 lik= ely 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 u= p
> with the chain
>
> A standard smartphone with average cellular downstream speed downloads=
> 2.6 headers per second (1600 kbits/sec) [3], so if synchronization wer= e
> 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 c= an
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G ha= s
worse range/coverage than 2G. No doubt the *average* is skewed so high beca= use
of densely populated areas like San Francisco having 400+ Mbps cellular dat= a.
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% eve= ry
> year.

Only in small densely populated areas of first-world countries.

Luke




---------- Forwarded message ----------
From:=C2=A0Gavin Andrese= n <gavinand= resen@gmail.com>
To:=C2=A0insecurity@national.shitposting.agency<= br>Cc:=C2=A0Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Date:=C2=A0Mon, 11 May 2015 13:29:02 -0400
Subject:=C2=A0Re: [= 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 t= he chain, and the only fair way to both secure the chain and distribute the= coins.

See=C2=A0https://gist.github.com/gavinandresen/630d4a6c24ac= 6144482a =C2=A0for some half-baked thoughts along those lines. I don= 9;t think proof-of-work is the last word in distributed consensus (I also d= on'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 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'd put a low probability on tha= t vision actually turning out to be correct.

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'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-de= velopment



-----------------------------------------------------------------------= -------
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d0418280825da600515d4398a--